Validating Documentation with Domain Ontologies

Do we always use the same name for the same concept? Usually not. While misunderstandings are always troublesome, they pose particularly critical problems in software projects. Requirements engineering deals intensively with reducing the number and scope of misunderstandings between software engineers and customers. Software maintenance is another important task where proper understanding of the application domain is vital. In both cases it is necessary to gain (or regain) domain knowledge from existing documents that are usually inconsistent and imprecise. This paper proposes to reduce the risk of misunderstandings by unifying the terminology of the different stakeholders with the help of an ontology. The ontology is constructed by extracting terms and relations from existing documents. Applying text mining for ontology extraction has an unbeatable advantage compared to manual ontology extraction: Text mining detects terminology inconsistencies before they are absorbed in the ontology. In addition to this, the approach presented in this paper also introduces an explicit validation of ontology gained by text mining. 1. Documents are Always Inconsistent Usually, some kind of requirements document is written in the beginning of a software project. After requirements elicitation, one of the first tasks of the software developer is to understand the requirements document which includes trying to understand the terminology used. But practical experiences show that apart from being imprecise, requirements documents also use inconsistent terminology. A simple steam boiler specification [1], written for a formal methods contest, for example, looked extremely precise at first glance. However, the document called the same measuring unit in different places “water level measurement device”, “water level measuring unit”, “device to measure the quantity of water”, . . . . Obviously, this unwanted obfuscation hampers understanding of the domain. The reader can not be sure whether there is just one unit or two or three different devices. And of course, real life specifications, not written for an academic formal methods contest, are very likely even less consistent. Furthermore, real life documents are usually much longer rendering manual detection and resolution of such inconsistencies virtually impossible. 1Correspondence to: Leonid Kof, Fakultaet fuer Informatik, Technische Universitaet Muenchen, Boltzmannstr. 3, D-85748, Garching bei Muenchen, Germany Tel.: +49 89 289-17834; Fax: +49 89 289-17307; E-mail: [email protected].